1. Field of the Invention
The present invention generally relates to software updates and in particular to the secure distribution of software updates in a distributed system.
2. Description of the Related Art
Many computer media or communication systems suffer from security holes that may allow unauthorized data access or the dissemination of worms. Thereby, considerable damage can be caused. Usually, such security holes are closed by means of security related software updates, also referred to as patches. In distributed systems, patches may be generated by a patch server and then distributed to a number of patch clients, for example, mobile units of a communications system or consumer devices having embedded processors.
However, patches loaded from an insecure system still need to be protected against malicious modification. Otherwise, a virus or worm could still cause effective attacks. For example, a denial of service (DoS) attack could be carried out against a GSM (Global System for Mobile Communications) net whereby only one infected active device per radio cell suffices to block the whole system.
In prior art systems, the public key cryptography (PKC), also referred to as asymmetric cryptography, is often used to protect package distribution by avoiding sending secret keys over insecure networks. The basic idea is that there are two keys: a public key (PK) which is applicable for encryption only and publicly known and a private key, also referred to as secret key (SK), that must be known to decrypt messages. The security relies on the difficulty in deriving the private key from the public key and the difficulty in deciphering an encrypted message without knowing the private key.
A special application of PKC is the digital signature. Here, a cryptographic hash sum over some document is computed and then this hash sum is encrypted with the creator's private key to create the digital signature. The signature is attached in some form to the document. Anybody who knows the creator's public key can compute the hash sum of the document, decrypt the attached signature with the public key and compare the result with the hashed document. Alternatively, the digital signature may be generated by decrypting the hash sum with the creator's private key. For verification, the receiver of the document may again calculate the hash sum, encrypt it with the public key and compare the result with the provided signature.
A correct digital signature proves that its creator knew the private key (authenticity) and that the document was not modified since the signature creation (integrity) neither by adding, deleting or modifying contents, nor by reordering parts of it. The latter is provided by the properties of the employed cryptographic hash functions, for example, MD5 (Message Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1) or RIPEMD-160 (Race Integrity Primitives Evaluation Message Digest 160). However, it cannot be seen, e.g., whether the private key was stolen during signature creation.
Asymmetric cryptography is often used for digital signatures, since also non-trusted parties, i.e., without knowledge of secrets are able to check the digital signature. However, PKC suffers from the disadvantage of being sensible and slow. In addition, security holes in PKC systems are due to possible man-in-the-middle attacks. This can be prevented if the authenticity of the public keys can be proven in some way. In some scenarios, it suffices to compute a cryptographic checksum over the public key, the so-called fingerprint, and to tell it to the receiver directly, e.g., via telephone. In complex and dynamically changing environments however, this is not possible. Therefore public key infrastructures (PKI) are used for this purpose where public keys are digitally signed by a hierarchy of trustworthy parties. Implementation and maintenance of a PKI infrastructure, however, is expensive.
In addition, there are a number of further risks and problems arising with PKC, for instance when RSA (Rivest-Shamir-Adleman) encryption is used. Beyond the slowness of PKC, plaintext portions are padded with random bits since otherwise, several attacks are possible. Therefore, plaintexts are usually not directly encrypted with public keys. Instead, a random session key is generated and used for traditional symmetric encryption, for example, using algorithms like AES (Advanced Encryption Standard) or Two-fish. In these protocols, referred to as hybrid protocols, only the session key is encrypted with the public key and added to the ciphertext.
However, even when using a hybrid protocol, the session key still has to be padded randomly to, e.g., 512 or 1024 bit lengths. Insufficient padding leads to reduced security.
Moreover, if a bit in a private RSA key is flipped by hardware or by an attacker and then this private key is used for defining a message, the public key can be factorized and thus the security is broken completely. This leads to considerable risks in PKC systems.
Furthermore, trapdoors can be implemented into the generation of public keys. An attacker knowing about the modifications of the creation algorithm will be able to deduce the private key easily from the public key, so that again the security is fully broken.
Therefore, many prior art patch systems try to avoid PKC. In systems where there is a dialog between trusted servers and clients like embedded processors (for example in GSM telephones), a serialized key (possibly in a smart card) and a challenge response protocol would provide a simple and robust solution. However, for many systems this is not applicable. For instance, when the receiver is fixed and passive during boot time, no serialization is possible.
Alternatively, prior art systems in which parties share common secrets use cryptographic checksums like HMAC (Keyed-Haching for Message Authentication). One example therefor is the authentication and key handling in GSM/UMTS (Global System for Mobile Communications/Universal Mobile Telecommunications System) mobile phones, where keys are distributed by SIM (Subscriber Identification Module) cards. This solution is simpler, faster and more robust than PKC. However, though an HMAC cryptographic checksum could prove integrity, the corresponding secret key would be fixed in the firmware of the EP (Embedded Processor) receiver. Thus, leaking this secret HMAC key would make all checksums valueless.
Therefore, many prior art patch systems use digital signatures. However, often assuring integrity is not enough. If patches are reverse engineered, security holes can be found nevertheless. A signed patch proves only its trueness, not its security. Security is provided only by trust in the author. Further, signing patches using the same public key for all patch clients suffers from the disadvantage of being considerably insecure. If the private key is leaked all security is lost. An even more probable scenario is one where the private key is lost. In this case, no more patches could be released and all patch clients would become more and more insecure.